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Abstract 

This report is a practical introduction to the use of SMILE, a system 
for microprogram load and examination. It is meant to familiarize new users 
with SMILE as one of the microprogram development aids in the microprogramming 
laboratory, and as a reference for advanced users. The organization of the 
SMILE system, input to be prepared by the user, and the interface with other 
microprogram development aids and the UNIX operating system are presented in 
the form of a tutorial. The report covers the basics needed for the use of 
SMILE, such as typing commands, operating the system from the processor console, 
and interpreting system responses. The concept and use of the SMILE system is 
demonstrated by an example. 



*SMILE, a System for Microprogram Load and Examination, was developed at the 
Technical University Berlin, Institut fllr Sof twaretechnik und Theoretische 
Informatik, Fachgebiet Betriebssysteme. 



1. Introduction 

SMILE is a system for loading and examining PDP-11/40E user microprograms. 
It was developed at the Technical University Berlin [1] . SMILE runs on the 
bare PDP-11/40E hardware and is bootstrapped from a magnetic tape. The orig- 
inal SMILE version is bootstrapped from a DECTAPE, TC11 [2], which is not 
available in our PDP-11/40E system configuration. The SMILE version we refer 
to in this report is a modification of the original version which is boot- 
strapped from the available magnetic tape, TM11[2]. The SMILE tape is gener- 
ated in a post-processing step following the assembly of a user microprogram 
with the MICRO/40 assembler [3]. 

The PDP-11/40E was developed at Carnegie-Mellon University [3,4]. It 
is a standard PDP-11/40 computer that has been extended by the following 
hardware features : 

IK 80-bit words of random access (RAM) control store for storing user 
microprograms. 

32 80-bit words of read-only (PROM) control store for bootstrapping 
microprograms. 

a 16-word stack for temporary data storage. 

- a shift and mask unit and a carry control unit which extend the data 
manipulation capabilities of the basic PDP-11/40 processor. 
The 3-Rivers Computer Corporation offers these hardware accessories as a 
writable control store option (WCS 11/40) for the PDP-11/40. All normal 
PDP-11/40 features are unaffected by the WCS 11/40. The design of this extension 
allows user microprograms access to all functional hardware units and data paths 
in the basic PDP-11/40 processor and in the WCS 11/40. Introductions to the 
microprogramming of the PDP-11/40E are given in [3,5]. 

The SMILE system is the control store loading facility in our PDP-11/40E 
microprogramming support system. Additionally, a microassembler [3,6] and a 
microsimulator [3,7] are available. These facilities constitute a typical 
microprogramming support system. More sophisticated support systems may also 
include test set generators, external hardware accessories for microporgram 
instrumentation, microprogram verification system, etc. As microinstructions 
affect all hardware resources in a computer and hence, faulty microprograms 
result in an erroneously operating machine, it is important that a micro- 
programming support system provides sufficient tools for microcode validation. 



The basic approaches to program validation are formal correctness proofs and 
testing. Proofs of formal correctness, which attempt to show the absence of 
errors, are not supported by our PDP-11/40E microprogramming system. Micro- 
code validation by testing is constrained by the fact that testing, in gene- 
ral, can only show the presence of errors, but not their absence. Micro- 
programming errors may occur at the microoperation level, the microinstruction 
level, and the microprogram level. The SMILE system provides testing facilities 
at the microprogram level. 

In general, we can distinguish between static program tests, via pro- 
gram analysis, and dynamic program test, via program execution. Syntax checks 
as performed by the MICRO/ 40 assembler may be considered as a type of 
static testing. Dynamic microcode test methods can be classified into soft 
(off-line) testing and hard (on-line) testing. The PDP-11/40E microcode 
simulator [7] is an off-line testing system that allows the examination of 
simulated microinstruction executions. The ability to detect dynamic, hard- 
ware-dependent timing errors with an off-line tester depends on the homoge- 
neity of the mapping of the machine hardware into the tester software. Therefore, 
on-line testing techniques are generally better suited for discovering dynamic 
errors in microprograms. The SMILE system allows on-line testing at the micro- 
program level. The microprogrammer can specify a PDP-11 machine language test 
program whose execution calls upon the execution of microprograms from the 
writable control store. The effect of microprogram execution in the physical 
machine can then be observed by investigating the appropriate processor reg- 
isters and main memory locations. In this respect, the SMILE on-line test 
facilities at the microprogram level complement off-line simulator tests at 
the microinstruction level. However, these testing tools do not lend them- 
selves to the location of dynamic errors at the microoperation level. Al- 
though the PDP-11 /40E microinstruction format facilitates the detection of 
microoperation timing conflicts in the MICRO/40 assembly process [6] , the 
provision of an on-line test system at the microoperation level is considered 
necessary. Therefore, the use of a logic state analyzer for this purpose has 
been investigated [8] . 

This report is a practical introduction to the use of the SMILE system. 
We first describe (section 2) the organization of the system. This description 
deviates from the original SMILE documentation [1] with respect to the modifi- 
cations which became necessary to install the system in our microprogramming 
laboratory. It includes guidelines for the operation of the SMILE system. 



The discussion in sections 2 and 3 is based on a simple example. With this 
example, the use of SMILE in microprogram development is demonstrated by a 
complete terminal session presented in section 3. 

2. SMILE Organization 

In this section, we describe the SMILE tape, as generated after micro- 
program assembly, and its constituent files. The discussion is based on the 
example microprogram , called fastc.mic, shown in Fig.l. This microprogram 
implements two machine language subroutines that handle the environment switch 
for subroutines calls in the "C" programming language of UNIX. It saves and 
restores registers that are used for parameter passing in subroutines calls. 
Further details of fastc.mic will be introduced as needed. 



reauire defs.mic 

bedin. naae 

»*20O18 d_210i b_d 

d_rir-b 'compare instruction 

skipzero 

d_211» b_d 

set 



start 
d_rir-b 
skipzero 
hoop 

set 



! check. for other instr. 



Soto 150 

start 1-211 instc 

d_p5 !rl<-r5 

ri_d 

d»ba_rl-2J rl_d !pop r4 

datiJ clkoff 

r4_unibus 

ba»d_rl-2» rl_d !pop r3 

datiJ clkoff 

r3_unibus 

b3td_rl-2> rl_d ! pop r2 

dati» clkoff. 

r2_unibus 

bafd_r5 !sp<-t5 

r6_d» datiJ clkoff. 

r5_unibus ! r 5<- ( sp ) -t 

d_r6+2f r6_d 

ba_r6» dati ! rts pc 

d_r6+2J r6_d* clkoff 

r7_unibusf but. 16 

goto 16 
end 



start !210 instr 

d»ba_r6-2J r6_d 'push r5 

d_r5» datoJ clkoff 

d_r7? p3 ... _ !r5<-r7 

r5_d 

rO_d . ! r0<-r5 

d_r6 Ir5<-r6 

r5_d 

drba_r6-2J r6_d !push>4 

d_r4» dato» clkoff 

d»ba_r6-2$ r6_d .'push r3 

d_r3* dato» clkoff 
d»ba_r6-2» r6_d Ipush r2 
d_r2J dato» clkoff 
d_r6-2J r6_d !r6<-r6-2 
d_rO Ir7<-r0 
r7_dJ but 16 
slota 16 
end 



tes 

•nd 



te.s 



finis 



Figure 1 : fastc.mic 



1) This microprogram was developed by K. Bullis, J. Bjoin, and T. Lunzer as 
a course project for (H.K. Berg) CSci 5299, Microprogramming, Winter 
Quarter 1978. 



2.1 Interface with MICRO/40 

User microcode for the PDP-11/40E is written in the MICRO/40 assembly 
language. For a detailed description of MICRO/ 40, the reader is referred to 
[6]. Microcode source files are generated using the UNIX text editor [9]. 
MICRO/40 microprogram source files must have names of the form 

<name>.mic, 
where <name> is any legal name, e.g., fastc. To assemble a microprogram 
source file, the UNIX command [10] 

mic [opt] <name>.mic 
is given. For use with the SMILE system, the options for assembler calls, 
opt, are not significant. The default assembler call, 

mic <name>.mic , 
which is used with SMILE, generates three files, namely <name>. 1st, <name>.bin s 
and <name>. tab(<name>. tab is only used by the micros imulator [7]). 
<name>. 1st 

This file is a listing of the microprogram object code in the 80-bit 
PDP-11/40E microinstruction format, followed by a list of mnemonic labels 
and their associated control store addresses. 

<name>.bin 



This file contains the binary version of the assembled microcode. It is 
generated from an internal file, <name>.s, in which a pseudo-readable form 
of the object microcode is stored in UNIX assembler format. The binary version 
of the assembled microcode, <name>.bin, is generated using the UNIX assembler 
as a post-processor of MICRO/40. 

When the assembly process is completed, the SMILE system can be invoked 
to load the object microcode into the writable control store, and to test the 
microcode at the microprogram level. As there is no protection mechanism 
built into the micro-architecture of the PDP-11/40E, the on-line execution of 
partially validated user microprograms has the potential to harm the system 
software. Therefore, the SMILE system is designed to run on the bare machine 
hardware. To this end, SMILE is bootstrapped from a magnetic tape. This 
tape is generated under the UNIX operating system. After the generation of 
the SMILE tape, the operating system is shut off (demount the system disk) 
to run SMILE. Following the execution of the SMILE tape, the user microcode 
is stored in the writable control store and the machine is available for 
normal operation. For instance, machine instructions may be executed which 



call upon the execution of user microprograms, or an operating system (e.g., 
UNIX) may be bootstrapped. 

Following microcode assembly under UNIX, the SMILE tape is generated by 
the UNIX command 

smile <name>.bin [<test program name>] . 
<test program name> is a file which contains the binary representation of a 
machine language program to be used for testing the user microcode at the 
microprogram level. The specification of a test program is optional. If 
the SMILE system is only to be used for loading microcode into the writable 
control, the SMILE tape can be generated by the UNIX command 

smile <name>.bin 

which does not refer to a test program. The SMILE tape consists of the following 
four files: 

the system loader, 

the RAM loader, 

the object code of the user microprogram (<name>.bin) , 

the object code of the machine language test program (<test program 

name>) . 

2.2 Organization of the SMILE Tape 

The UNIX command ' smile' is a program that generates the SMILE tape. 
This program is written in the "C" programming language of UNIX [11]. It 
checks the status of the magnetic tape drive, TM11. If the tape drive is 
not ready for writing, the error message, 

cannot open /DEV/TM11/ , 

is printed and the program halts. Otherwise, the subroutines TWRITE is 
called to write each of the constituent SMILE files on the magnetic tape. 
As the user microprogram and the test program are variable in size, TWRITE 
attaches the file headers (specifying the size) to these two files. Addi- 
tionally, the program symbol table is included in the test program file. 
For each file that is written on the tape, the subroutine TWRITE prints the 
following message, 

<file name>: <# bytes>/<max// bytes>bytes <// blocks >/<max# blocks>blocks 
where <# bytes> and <# blocks> are the numbers of bytes and blocks, respectively, 
in the file to be written, and <max# bytes> and <max# blocks > specify the allowed 
maximum size of the file <file name>. The block size on the TM11 7-track tapes 
used in our microprogramming laboratory is 512 bytes, which corresponds to 256 



words. If the subroutine TWRITE is for some reason unable to properly write 

on the magnetic tape, the program halts after printing one of the error messages 

listed in Table 1. 

cannot open /DEV/TMll/ If the device is not ready for writing. 

cannot open <f ile name> If one of the SMILE files cannot be 

read from the UNIX file system. 

too many bytes If <# bytes > exceeds <max# bytes>. 

too many blocks If <# blocks> exceeds <max# blocks>. 

read error on <file name> If a read error occurs when reading from 

the UNIX file system. 

write error on tape If a write error occurs when writing onto 

the tape. 

more blks written than read If the number of blocks written on the 

tape is greater than the number of blocks 
read from the UNIX file system. 

Table 1; Smile Command Error Messages. 

After the program 'smile' has been executed, the generated magnetic tape 
has the format shown in Fig. 2. 

Block ; As the bootstrap program in our system skips block 0, the first block 
on the tape contains no information. 

Block 1 : This block contains the SMILE system loader. The system loader's 

size is 146 bytes and hence, bytes 222 to 777 of this block are not used. 

o o 

Block 2 ; This block contains the RAM loader. Its size is 226 bytes, leaving 

bytes 342„ to 777 R of this block empty. 

Blocks 3 to i : The object code of the user microprogram, <name>.bin, to be 
loaded into the writable control store is stored in these blocks. As the size 
of this file is variable, a file header is attached to it. This file header 
has the format of the UNIX object file header [9]. The following two of the 
eight header words are of interest. Word 2 specifies the size of the file in 
number of bytes. The microassembler stores the size of the microcode file 
in blocks into word 7 which is unused in UNIX. For the microcode file, 
<max# blocks> = 21 and hence, <max# bytes> =10752. The file header is stored 
in a separate block. The remaining 20 blocks correspond to 5K of 16-bit words 



Block Number 



Skipped by the 
bootstrap program 

System Loader 



RAM Loader 



User Micro 
program (RAM ^ 
contents) 
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W//M/WM//MM/WM. 


^WW/WM/WMMM/M 


HEADER 







Test Program 



Unused 




i + 1 



i + 2 



i + j 



Figure 2: SMILE Tape layout (the shaded areas do not contain information) 



for the user microcode (cf. Fig. 4 in the following subsection). 

Blocks i + 1 to i + j : These blocks contain the object code of the machine 
language test program, <test program name>, and the associated program symbol 
table. As this file is of variable size, a file header is attached. Its size- 
is specified in the same way as for the microcode file; Additionally, the 
size of the program symbol table in bytes is stored in word 5 of the file header 
For the test program, we have <max# blocks> = 89 and <max# bytes > = 19952. In 
this file, the file header is not stored in a separate block and hence, the 
test program can be up to 22. 5K 16-bit words long (cf. Fig. 4 in the following 
subsection) . 

The SMILE tape for our example microprogram as generated by the command 

smile fastc.bin a. out 
is shown in Fig. 3. The UNIX file a. out contains the binary object code of 
the test program. This file exists as long as no other program is assembled 
or compiled, since object programs generated under UNIX are always stored in 
this file. If it is desirable to preserve the object code of a test program, 
the file a. out can be saved into a user file, <name of test program>, by the 
UNIX command 

mv a. out <name of test program>. 
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172522 
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012701 


133000 


005061 


Loader 


0001040 


000020 


004767 


000106 


016102 


000014 


060002 


005200 


016101 




0001060 


000020 


004767 


000044 


000000 


012701 


000760 


005061 


000014 




0001100 


004767 


000050 


016102 


000014 


060002 


005200 


062701 


001000 




0001120 


004767 


000006 


000000 


000137 


000400 


020002 


002401 


000207 




0001140 


004767 


000010 


005200 


062701 


001000 


000767 


010165 


000004 




0001160 


012765 


177000 


000002 


012715 


060003 


004767 


000002 


000207 




0001200 


032715 


100200 


001775 
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000207 


013700 


172520 


000000 




0001220 
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000000 


000000 


OCOOOO 


000000 


000000 


000000 


00000Q 
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(Octal) 
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0002000 


















RAM 


013746 


133772 


004767 


000060 


010002 


010003 


013716 


133774 




0002C20 


062716 


000010 


004767 


000040 


005726 


005005 


062205 


005505 


Loader 


0002040 


020200 


103774 


020537 


133776 


001422 


012700 


000001 


004767 




0002060 


000246 


010537 


133776 


000744 


016600 


000002 


162700 


020000 




0002100 


010001 


006201 


C06201 


060100 


062700 


134000 


000207 


032737 




0002120 


000001 


177570 


001005 


012700 


170000 


004767 


000172 


000767 




OC02140 


013746 


177776 


05273/ 


000200 


177776 


, 005005 


013701 


133772 




0002160 


012704 


000652 


011300 


005002 


000007 


010702 


000007 


020023 




0002200 


001031 


060005 


005505 


062401 


020427 


000662 


101763 


020137 




0002220 


133774 


003756 


012637 


177776 


020537 


133776 


001421 


J 2700 
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000002 


012746 
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000167 


000056 


000002 


000002 


000002 
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037772 
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012700 
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Block 3 

Header 

fastc.bin 



Byte 
Number 
(octal) 

J 



kbytes 

1 



^blocks 

4 



File Header— * 0003000 000407 001 662 000000 000000 000000 000000 000002 000001 
0003020 134000 134670 000000 000000 000000 000000 000000 00000Q 
0003040 000000 

Control — » 0003760 000000 000000 000000 000000 000000 020000 020540 060615 
Information ■ f t f 

ramfrst ramlast chcksum 



Block 4 
fastc.bin 



Control 
Information 



Byte 
Number 
(Octal) 

I 
0004000 
0004020 
0004040 
0004060 
0004100 
0004120 
0004140 
0004160 
0004200 
0004220 
0004240 
0004260 
0004300 
0004320 
0004340 
0004360 
' 0004400 
• 0004420 
0004440 
0004460 
0004000 
0004520 
0004540 
0004560 
0004600 
0004620 
0004640 
0004660 
0004700 
' 0004760 



000000 
006371 
003057 
000000 
100410 
100000 
002365 
000000 
000000 
046000 
000000 
002355 
000000 
000000 
066020 
100026 
002345 
000000 
000000 
140400 
100020 
002335 
003057 
000000 
120520 
000022 
002325 
000000 
000000 
000000 



000000 
000210 
146610 
000025 
002370 
000000 
000000 
046000 
000000 
002360 
000000 
000000 
060020 
020025 
002350 
004457 
000000 
0460C0 
000025 
002340 
000000 
000000 
1466.10 
100026 
002330 
000000 
000000 
046000 



040000 
000033 
002342 
000000 
000000 
141400 
000000 
002363 
000000 
000000 
060020 
100021 
002353 
000000 
000000 
146400 
100026 
002343 
000000 
000000 
046000 
100025 
002333 
003057 
000000 
120520 
000020 
002323 



002376 
003000 
000000 
100400 
005000 
006375 
000000 
000000 
060020 
100021 
002356 
003057 
000000 
100600 
040025 
002346 
004457 
000000 
120520 
100025 
002336 
000000 
000000 
146610 
100026 
002326 
000000 
000000 



000000 
100410 
000000 
002364 
000000 
000211 
040000 
100021 
002361 
003057 
000000 
146610 
040022 
002351 
000000 
000000 
166400 
000000 
002341 
000000 
000000 
046000 
000024 
002331 
003057 
000000 
100400 
000000 



100000 
002366 
000000 
000000 
040000 
005000 
002373 
0030:57 
000000 
146610 
040023 
002354 
000000 
000000 
046000 
020026 
002344 
000000 
000000 
046000 
000026 
002334 
000000 
000000 
146610 
100026 
002324 
000000 



000000 
000000 
040000 
000033 
002367. 
000000 
000000 
146610 
040024 
002357 
000000 
000000 
046000 
100026 
002347 
000000 
000000 
040000 
000027 
002337 
000000 
000000 
120520 
000023 
002327 
003057 
000000 
040000 



141400 
100026 
000227 
003000 
000000 
040000 
100021 
002362 
000000 
000000 
04600Q 
000000 
002352 
00000Q 
000000 
040220 
047027 
000361 
000000 
000000 
100400 
100026 
002332 
000000 
000000 
146410 
107027 
00036L 



000000 000000 000000 000000 



020000 020540 060615 

r t t 

ramfrst ramlast chcksum 



Block 5 
a. out 



File Header' 



Byte 
Number 
(Octal) iPbvtes 

^ '■'> 

0005000 000407 000054 

0005020 012700 000000 

0005040 012704 000004 

0005060 005000 005001 



length 

symbol 

table ^blocks 

4, . V 

000000 000000 000000 000000 000001 000000 
012701 000001 012702 000002 012703 000003 
012705 000005 012706 133000 000210 000000. 
005002 005004 000211 000000 



This test program file does not not contain a symbol table 



Figure 3 : Smile Tape Example 
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2.3 System Loader 

The system loader is the first file on the SMILE tape (block 1). It 

is brought into main memory by bootstrapping the SMILE tape. The main memory 

locations ft to 376 ft are reserved for the SMILE system loader. The bootstrap 

program places it into locations o to 110 o and then transfers control to the 

o o 

first instruction of the system loader and halts. The system loader is invoked 

by pressing the CONTINUE switch at the processor console. It loads the RAM 

loader, the microcode, and the test program into main memory, thus, creating 

the main memory map as depicted in Fig. 4. To load these files requires that 

the system loader is reinvoked for each file by pressing the CONTINUE switch. 

The implementation of the system loader is based on the fixed SMILE tape 

format as discussed in the preceeding subsection. It is written in PDP-11/40 

assembly language and makes no use of the memory management [12] . Hence, the 

main memory map shown in Fig. 4. is a description of the lower 28K words of 

physical memory. 

The SMILE system loader first reads the RAM loader (block 2) from the 

magnetic tape into main memory locations 400 o to 741 . In the main memroy 

o o 

map, locations 400 R to 756~ are reserved for the RAM loader. 

Next, the first block of the microcode file, which contains only the 
file header and some control information (cf. Fig. 3) , is read from the magnetic 
tape. From this block, the size of the object microcode is calculated. Then, 
the rest of the microcode file is read into main memory. Location 134000,. to 
1577 7 6 ft are reserved for this purpose. The maximum length of the object micro- 
code corresponds to the maximum writable control store capacity of IK 80-bit 
words. The 10K bytes are mapped into the highest 5K of 16-bit main memory words 
(23K to 28K) as follows. The increment of control store addresses from one 
80-bit RAM-word to the next is 010 o [5], whereas the increment of main memory 
addresses from one 80-bit RAM-word to the next is 10 (decimal) bytes. Hence, 
we have 

memoffset = ramof f set •5/4 # 
with the control store address of the first 80-bit ramO =2000 o , we have 

o 

ramof f set = ramadr - ramO. 
If we denote the main memory address of ramO by ram_c, and with ram_c = 134000„, 
the main memory address corresponding to a given control store address is 
calculated as follows 

memadr = ram_c + memoffset 

= ram_c + (ramadr-ramO) »5/4» 
Using this relationship, the user may perform smaller modifications of the 
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Figure 4 : Main Memory Layout 
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object microcode from the processor console, without reinvoking the micro- 
assembler and generating a new SMILE tape. The bit assignment of the micro- 
operation fields in the 80-bit RAM word are discussed in [3,5] . 

The last eight words of the first and last block in the microcode file 

on the tape contain control information (cf. Fig. 3). The first five of 

these control words are empty. Words 6 and 7 specify the first (ramfrst) 

and last (ramlast) control store addresses to be loaded with the microcode 

in the file. The addresses ramfrst and ramlast are stored in the main memory 

locations 133772 and 133774 respectively. Word 8 of the control information 
o o 

contains a check sum (chksum) which is stored in location 133776ufor later 

use by the RAM loader. 

Finally, the system loader transfers the object code of the test program 

from the magnetic tape into main memory. In this case, the file header and 

the object code contained in the first block of the file (cf . Fig. 3) are 

stored in main memory starting at location 000 760 o . That is, the file header 

8 . . 

is stored in locations 000 760 o to 000 776 and the object code of the test 

o o 

program starts at location 001 000 o . The size of the test program file is 

o 

calculated from the information in the file header, and then, the rest of this 

file is read from the magnetic tape. 

Locations l000 o to 132776 are reserved for the storage of the test program 
o o 

and its program symbol table. Test program file is stored, starting at main memory 

location 1000~. However, the test program file must not completely fill the reserved 

22. 5K main memory words as main memory location 132776 Q to R are used for the 

o 

stacks in the system loader and the RAM loader. This stack should also be 

used by the test program (if this program contains stack instructions) . It 

is the user's responsibility to prevent overwritting of the test program by 

the stack. As a general rule, the reservation of ten main memory words for 

the stacks in the system loader and RAM loader is sufficient. 

Main memory locations 760 000 o to 777 776 Q as shown in Fig. 4 are reserved 

o o 

for PDP-11 device register addresses. These locations correspond to the 16-bit 
addresses 160 000 g to 177 776 g which are automatically relocated by setting 
the address bits 16 and 17 in the 18-bit UNIBUS address to 1, if the address 
bits 13, 14, and 15 are 1. With the memory management option [12], the main 
memory space may be extended from 28K as shown in Fig. 4 up to 124K words 
(locations 160 000 o to 757 776 ). 

o o 

If an error occurs when the system loader reads the SMILE tape, an error 

subroutine is called which stores the address of the currently written main 
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memory word into the processor register R[0] . Then, the program halts and 
the content of R[0] is displayed on the data display at the processor console. 
Thus, using the main memory map given in Fig. 4, it can be determined how 
much of the SMILE tape had been read at the time the error occured. When 
the system loader terminates after loading the entire SMILE tape, it is no 
longer needed. Hence, the test program can use its memory space for the stor- 
age of interrupt vectors [12] ( c f. subsection 2.5). 

2.4 RAM Loader 

After the entire SMILE tape has been transferred into main memory, the 
system loader transfers control to the first instruction of the RAM loader at 
location 400« and halts. The RAM loader is invoked by pressing the CONTINUE 
switch at the processor console. It loads the object code of the user micro- 
program from main memory into the writable control store locations specified by 
ramfrst (main memory location 133 772 ) and ramlast (main memory location 

o 

133 774_ ). The implementation of the loader is based on the main memory map 
of the 80-bit RAM-words as discussed in the preceeding subsection. It is 
written in the PDP-11/40 assembly language. 

The control store loading process is controlled by check sum tests and 
Immediate rereads from the control store. These tests are preformed to 
ensure that the microcode loaded into the control store is equivalent to the 
microcode generated by the microassembler. To this end, the RAM loader first 
calculates a check sum of the main memory words to be transferred into the 
control store and compares it with the check sum that was produced by the micro- 
assembler (chksum in main memory location 133 776 Q ). If the two check sums 
agree, the microcode can be loaded into the control store. Otherwise, the RAM 
loader issues an error message and halts. The user may request continuation of 
the loading process by pressing the CONTINUE switch at the processor console. 
In this case, the checksum calculated by the RAM loader is written into location 

133 776_ and the check sum test is repeated, 
o 

This option has been built into the RAM loader to allow for immediate mod- 
ifications of the user microprogram. The checksum of the original object micro- 
code is automatically replaced by a checksum for the modified object microcode. 
Hence, it is possible to make smaller modifications in the object code of the 
user microprogram, without invoking MICRO/40 under UNIX for reassembling a mod- 
ified source microprogram and generating a new SMILE tape. Such modification may 
even be made after the microprogram has been tested. In this case, control must 
manually (at the processor console) be transferred to the beginning of the Ram loader 
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For this reason, the main memory locations of the RAM loader should not be 
changed by the test program. 

During the control store loading process, the RAM loader immediately 
rereads each transferred 16-bit word from the control store and compares it 
with the appropriate main memory word. If the two 16-bit patterns disagree, 
the WRITE operation can be repeated by pressing the CONTINUE switch. Further- 
more, after the entire RAM map has been written into the control store, the control 
store content is reread and a checksum is calculated. If this checksum dis- 
agrees with the check sum stored in location 133 776 Q , the checksum in location 

o ■ ■ . . 

133 776 R is checked by recalculating a new checksum for the microcode in main 

memory and a new control store loading process can be initiated by pressing 

the CONTINUE switch. 

The RAM loader informs the user of the status of the control 

store loading process by generating the encoded error messages listed in Table 

2. To alert the user, the console 'peeps' and the message code is displayed 

on the data display. At this time, the program halts at location 000 740 

8 

which is displayed on the address display. When the CONTINUE switch is pressed, 
the program continues execution according to the displayed message code. The 
actions performed after the program is restarted are described in Table 2. 

The RAM loader has a built-in safeguard against unintentional modifications 
of the writable control store. This protection mechanism is based on the fact 
that all hardware bootstrap programs start at even (word) addresses. There- 
fore, in contrast to the general rule, it is required that the bitO-switch (lowest 
order bit) is set to 1 (odd address) when the control store loading process is 
initiated. The position of the bitO-switch is tested after the first check 
sum test has successfully been passed. When the bitO-switch is set to 0, the 
program halts until the switch is set to 1 and it is reinitiated by pressing 
the CONTINUE switch. 
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Code 000 000 

The RAM has been loaded without error. When the CONTINUE switch is 

pressed, the testprogram will be executed, starting from location 001000 o 

o 

Code 000 001 

The checksum stored in location 133776 Q disagrees with the checksum cal- 

o 

culated by the RAM loader. When the CONTINUE switch is pressed, the 

RAM loader checksum will be stored in location 133776 and the checksum 

o 

test is repeated. 

Code 000 002 

The checksum calculated upon immediate reread of the written object micro- 
code from the RAM disagrees with the checksum stored in location 133776 . 
When the CONTINUE switch is pressed, a new RAM load is tried. 

Code 000 010 

The immediately reread 16-bit word disagrees with the 16-bit word written 
into the RAM. When the CONTINUE switch is pressed, a new WRITE/READ for 
the same 16-bit word is tried. 

Code 017 000 

A control store loading process has been initiated with the bitO-switch 
set to 0. When the CONTINUE switch is pressed, the test of the bitO- 
switch is repeated. 

Table 2 : RAM Loader Message Codes 

2.5 Test Program 

The test program for testing user microcode at the microprogram level is 
a PDP-11/40 machine language object program. The source of the test program 
is written in the UNIX assembly language. This is indicated by the suffix "s" 
in test program names of the form <name>.s. The object code of the test 
program is to be generated and stored in the file a. out by the UNIX command 

as <name> . s , 
before the generation of the SMILE tape (with the microcode object file 
<name>.bin) is invoked by the UNIX command 

smile <name>.bin a. out 

As the system loader loads the test program into consecutive main memory 

locations, starting from location 001 000 o (cf. Fig. 4) , instead of 000 000 o , 

o o 

the first instruction in the test program must set the assembler's relocation 
counter (..) to this address. The appropriate instruction is 

.. =1000 . 
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This initialization is necessary to have correct program-counter-relative 
addresses produced by the UNIX assembler. 

When the RAM loader terminates with a message code 000 000 (cf . Table 2), 
pressing the CONTINUE switch invokes the execution of the test program. All 
instructions in the test program which have an unused PDP-11/40 op-code 
transfer control to one of two entry points into the control store [3,5]. 
Decoding of such an op-code by the user microcode in the writable control store 
calls upon the execution of the microprogram which defines the unused op-code. 
In the assembly language, unused op-codes may either be represented by an octal 
number or may be assigned a mnemonic representation, <code>, as follows [11]. 

(a) No Operand Instructions 

<code> = <octal number> 

(b) Single Operand Instructions 

<code> = <octal number> A tst 

(c) Double Operand Instructions 

<code> = <octal number> A mov 

Note that <octal number> must always represent an unused PDP-11/40 op-code [5,12] 

The source code of a test program, called testn.s, for our example micro- 
program (cf. Fig. 1) is shown in Fig. 5. 

..=1000 



mov 




$0,r0 


mov 




$l,rl 


mov 




$2.r2 


mov 




$3,r3 


mov 




$4,r4 


mov 




$5,r5 


mov 




$133000, sp 


210 











/ halt 


: 211 






clr 


ro 




clr 


rl 




clr 


r2 




clr 


r3 




clr 


r4 




211 







/ halt 



Figure 5 : testn.s 



The first segment of testn.s tests the (unused) instruction 210 o which is 

o 

implemented by the microcode in the right column of Fig. 1. This instruction 
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saves registers R[2],R[3], and R[4] by pushing them onto a stack (for a 

subroutine call). The second segment of testn.s is a test for the (unused) 

instruction 211 whose implementation is given in the left column of Fig. 1. 

Instruction 211 ft restores registers R[2] , R[3] , and R[4] by popping them 

off the stack (for a return from subroutine) . Instructions 210 o and 211 

8 8 

are no operand instructions and are represented by octal numbers in testn.s. 
The test for instruction 210 o loads constants into registers R[0] to 

o 

R[5] and sets the stack pointer sp (R[6]). It then executes instruction 210 o . 

o 

A halt instruction (op-code 000 Q ) follows. Hence, when the execution of 

o 

testn.s halts, the register contents can be examined by displaying them on the 

data display at the processor console. Pressing the CONTINUE switch invokes 

the execution of the test for instruction 211_. The appropriate section of 

o 

testn.s clears registers R[0] to R[4], executes instruction 211_, and halts. 

o 

Again, the register contents can be examined. The microcoded implementation 

of instructions 210 o and 210 o can then be checked at the microroutine level 

o o 

by comparing the register contents obtained after the execution of instruction 

211 with the original content of the registers. 

When the test program is first initiated, following the execution of the 

RAM loader, the stack pointer sp is automatically set to the value 133 000 o . 

o 

Before the first value is pushed onto the stack, sp is decremented by 2 and 

hence, the last element in the stack is always stored at location 132 776 

o 

(cf. Fig. 4). The SMILE system automatically initializes the stack for use 

by the test program. However, if the test program is restarted from the 

processor console, the stack pointer sp is not reset. In this case, care must 

be taken that stack instructions in the test program are not affected by 

"garbage" in the bottom of the stack. Therefore, it is advisable to always 

reset the stack pointer sp in the test program, as done in testn.s (cf . Fig. 5) 

Moreover, this measure may also help to prevent unintentional overwriting of 

the test program by the stack. Nevertheless, the user must always make sure 

that the test program does never overlap with the test program stack. For 

this purpose, the SMILE system retains the header of the test program file 

in locations 000 760 o to 000 776 , such that the memory locations occupied 

o o 

by the test program can always be calculated from the byte count stored in 
location 000 762 R (second word in the file header) . 

As mentioned before, the test program may use locations 0q to 376 R 
(which are generally reserved for the system loader) for the storage of 
interrupt or trap vectors. However, as the SMILE system runs on the bare 
machine, interrupt or trap vectors to be used in the test program must be 
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initialized in the program. Furthermore, the test program must also handle 
interrupts or traps. The general structure of an interrupt/ trap vector is 
depicted in Fig. 6. The address assignment for PDP-11/40 interrupts vectors 
can be found in [12] . 

15 



Pointer to Service Routine 



New Processor Status Word 



Figure 6 : Interrput/Trap Vector 



An example for the use of a trap vector in a SMILE test program is 
demonstrated by the test program, test.s, as shown in Fig. 7. 



. .=1000 



mov $a,*$10 
mov $3,*$12 
mov $133000, sp 
212 

a: 

Figure 7 : test.s 

This test program is used with the example microprogram, fastc.mic, as de- 
picted in Fig. 1. It tests if illegal instructions (unused op-codes other 

than 210 o or 211 ) are recognized by the decoding in fastc.mic and trapped 
o o 

correctly. The first instruction of test.s stores the address of label 

'a f into location 010 o (location of the interrupt vector for 'Reserved 

o 

Instruction 1 [12]). The second instruction assigns the (arbitrary) value, 3 

to the associated processor status word entry at location 012_. If instruction 

212 R is trapped properly, test.s halts at label 'a' with the value 3 stored 

in the processor status register. If the microprogram fastc.mic does not 

recognize instruction 212 as an illegal instruction, test.s halts at the 

o 

halt statement immediately following instruction 212- . 

An example for the implementation of an interrupt service routine is 
shown in Fig. 8. 
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mov $int,*$10 

/set interrupt vector for reserved 
instruction 
int: mov (sp) , rO 





/display the address of the interrupt 
vector that caused the halt on the 
data display 
rti 

Figure 8: Interrupt Handler for Reserved Instructions 

The last instructions of an interrupt /trap service routine should be 
halt and rti (return from interrupt), rti restores the program counter and 
the processor status word from the processor stack. Thusy after the cause 
of an interrupt or trap has been investigated, the test program execution 
may be continued by pressing the CONTINUE switch. 



3. SMILE Operation 

In this section, a terminal session is presented which demonstrates 
assembling, loading, and testing of the example microporgram fastc.mic. 
The microprogram and the test program testn.s are assumed to be stored 
under the directory /uprog/. System commands and responses start at the 
left margin of the page. System responses end with the prompt %. 

3.1 Preparation of the SMILE Files 

The microcode file and the test program file are prepared before the 
SMILE tape is generated . 

mic /uprog/ fastc.mic 

The microporgram fastc.mic is assembled, 
/uprog/f astc .mic 
91 lines read. 
% 

Now, the files fastc.lst, fastc.bin, and fastc.tab may be printed 

strip fastc.bin 
% 
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The symbol table is stripped off the file fastc.bin, as it is 
not needed by the SMILE system. 

as /uprog/testn.s 
% 

The test program testn. s is assembled by the UNIX assembler, and the 
object code is stored in the file a. out. 

mv a. out testn 
% 

The object code of the test program is moved from a. out to the file 

named testn. 

3. 2 Mounting the Tape 

When the microcode object file, the test program object file, the system 
loader, and the RAM loader are allocated under the user working directory, a 
magnetic tape is mounted. 

1. Mount the tape on the tape drive 

2. Push the POWER switch into the on-position. The WRITE ENABLE light turns 
on . 

3. Push the LOAD switch. 

4. Push the ON LINE switch. The READ and SELECT lights turn on. 

5. The tape drive is ready. 

3.3 Generation of the SMILE Tape 

The UNIX command "smile" is assumed to be stored under the directory 
/uprog/bin/. 
/uprog/bin/ smile fastc.bin testn 

This command generates the SMILE tape which contains the system loader, 

the RAM loader, the object microcode fastc.bin, and the object code and 

the symbol table of the test program testn - 

fastc.bin: 962/10752 bytes 2/21 blocks 
testn: 60/-19952 bytes 1/89 blocks 
done 
% 

For the microcode and the test program, the system specifies the number 
of bytes and blocks to be written on the tape and the allowed maximum 
size of these two files. Then, the completion of the SMILE command 
execution is indicated. 
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3.4 System Halt 

When the SMILE tape is generated, the system is halted to load the 
tape into the bare machine, 
halt 

Halt the system 
halt the system? y 

The system reassures the halt command. With the user response "y"> 

the system halts and prompts 
UNIX halted. 
@ unix 

After the system halts, the load switch on both disks must be pushed to 
the LOAD position such that the read/write heads are fully retracted and 
the spindle stops rotating. 

3.5 Bootstrapping the SMILE tape 

The SMILE tape is bootstrapped from the processor console. 

1. Set address 773 130,, at the switch register. 

2. Push LOAD ADRS switch. 

3. Push START switch to load the system loader into main memory. 

4. CPU halts. 

5. Push CONTINUE switch to start the system loader. 

6. CPU halts. 

7. Push CONTINUE switch to load the RAM loader. 

8. CPU halts. 

9. Push CONTINUE switch to load user microcode file 

10. CPU halts. 

11. Push CONTINUE switch to load the test program. 

12. CPU halts. 

13. Push CONTINUE switch to transfer control to the first instruction of 
the RAM loader. 

14. Console "peeps", the console address register displays 000740 g , and 
the console data register displays 170000 g (cf. Table 2). 
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3.6 Control Store Loading 

The control store loading process is controlled according to the RAM 
loader messages listed in Table 2. 

1. Set bitO-switch to 1. 

2. Push CONTINUE switch 

3. When the console "peeps' follow Table 2 until the RAM loader holds at 

location 0Q0740 o and the code 000 000 o is displayed on the console data 
o o 

display. 

3.7 Test 

When the control store has successfully been loaded, pushing the CONTINUE 

switch invokes the execution of the test program. When the test program 

executes a 'halt' instruction, register contents and main memory locations 

i 
can manually be examined at the processor console, (the test program might 

also include an output routine that prints the desired register contents on 

the DEC-writer). 

1. CPU halts. 

2. Set register or main memory address at the switch register. 

3. Push LOAD ADRS switch. 

4. Address in switch register is displayed on the address display. 

5. Push EXAM switch. 

6. Content of specified location is displayed on the data display. 

7. Push CONTINUE switch (if more test program instr. are to be executed). 



For the test program, testn.s, (cf. Fig. 5) the following register 
contents are obtained after the execution of instruction 21Q_. 



Address 


Register 


Content 


Comment 


777 700 


R[0] 


001036 


Address of halt instruc 


777 702 


R[l] 


1 




777 704 


R[2] 


2 




777 706 


R[3] 


3 




777 710 


R[4] 


4 




777 712 


R[6] 


132776 


Stack start address 


777 714 


R[6] 


132766 


Stack pointer 


777 716 


R[7] 


001040 


Current program counter 
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The stack content observed after the execution of instruction 210 o is given 

o 

below. 



Address 



Content 



Comment 

Content of R[5] 
Content of R[4] 
Content of R[3] 
Content of R[2] 
Scratch value 



After the execution of instruction 211_ registers R[l] to R[4] contain the 

o 



132 776 


5 


132 774 


4 


132 772 


3 


132 770 


2 


132 766 






following values. 



Address 

777 702 

777 704 

777 706 

777 710 



Register 

R[l] 
R[2] 
R[3] 
R[4] 



Content 

132770 
2 
3 
4 



Comment 

Stack address of R[2] 

Restored from location 132 770 

Restored from location 132 772 

Restored from location 132 774 



3.8 Bootstrapping UNIX 

When the user microcode has been loaded into the control store and has 
been examined by the test program, it may be desirable to bootstrap the 
operating system. The UNIX bootstrap requires the EIS (extended instruction 
set) microcode in the writable control store. If the user microcode contains 
the EIS microcode, bootstrapping UNIX starts from step 4 of the bootstrap 
sequence given below. Otherwise, the user microcode in the control store 
is overwritten by the EIS microcode, when the following bootstrap sequence 
is carried out. 



1. Mount the EIS SMILE tape (labelled EIS). 

2. Bootstrap the EIS SMILE tape (cf. subsection 3.5). 

3. Load the EIS microcode into the control store (cf. subsection 3.6). 

4. Load the UNIX disk on disk drive 0. 

5. Push LOAD switch at disk drive to RUN position. 

6. Wait for the RDY or the ON CYL light to come on. 

7. Set address 773 100 o at the switch register. 

o 

8. Push LOAD ADRS switch. 

9. Set ENABLE/HALT switch to ENABLE 

10. Push START switch. 

11. The system responds with @ on the DEC-writer. 

12. Type 'unix' and push return key. 

13. The system types an identification and asks for the date to be typed. 

14. Set the date. 

15. UNIX is up and prompts with 'login:*. 
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